iT邦幫忙

2021 iThome 鐵人賽

DAY 18
0

緣起

Use Case 的職責是把業務邏輯封裝,一個 Use Case 大致可以對應到一個 User Story。一開始我們對 Use Case 要怎麼設計並沒有太多想法,便開始整理以前的 User Story,發現大部分都可以歸納成

取得資料 → 業務邏輯 → 儲存資料

而單元測試內則是,"取得資料"對應到"建立測資",業務邏輯則是測試的重點,"儲存資料"則應該被mock 或 stub 掉,因此第一版的 Use Case 設計的兩個對外的 method,一個是 create, 放業務邏輯,如果業務邏輯過長則可以用 private method 封裝,另一個則是 save ,放儲存資料的程式或 call 第三方服務,而在測試中只測 create

這邊簡單用建立訂單舉一個例子

這時候 Boxenn DAL 的介面還沒設計出來

# Use Case 大概長這樣子
class CreateOrder
	def initialize(params:)	
		@params = params
	end

	def create
		# 其他邏輯 (如驗證、處理參數等等)		
		@order = Order.new(params)
	end

	def save
		@order.save!
	end
end

use_case = CreateOrder.new(params: params)
use_case.create
use_case.save

這樣做其實有不少缺點:

  • 外部需要 call 兩個 method
  • 處理資料與儲存資料不在一起,遇到需要同一個交易內的資料操作時,只能在use case外面包
  • 沒有統一的回傳格式
  • 例外處理需額外寫

這時候我們發現了 dry-monads ,他的核心理念是 functional programing 當中的 monad。

關於 monad 的解釋可以看以下資料

https://ithelp.ithome.com.tw/upload/images/20211002/20108265ltkoolWh6S.png

那這樣做的好處是:

  • 對外只有唯一的 method 可以 call
  • 能處理錯誤 (可以在每一步定義)
  • 容易閱讀
  • 有了 Boxenn DAL 的輔助後,容易測試,也可以走 TDD

到此,我們的 Use Case 介面便有了雛形。
下一篇將會介紹 Boxenn::UseCase 的實作細節,以及如何使用。


上一篇
[DAY17] 關於 DAL 的一些問題
下一篇
[DAY19] Boxenn 實作 Use Case
系列文
在 Ruby on Rails 中導入 Domain-Driven Design 是不是搞錯了什麼?30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言